erts: Add BIFs processes_iterator/0 and processes_next/1
#9129
Conversation
CT Test Results 5 files 211 suites 1h 54m 20s ⏱️ Results for commit 69f7884. ♻️ This comment has been updated with latest results. To speed up review, make sure that you have read Contributing to Erlang/OTP and that all checks pass. See the TESTING and DEVELOPMENT HowTo guides for details about how to run test locally. Artifacts// Erlang/OTP Github Action Bot |
lucioleKi
force-pushed
the
isabell/erts/processes_iterator
branch
from
9b38bf1 to
72b2c22
Compare
lucioleKi
added
the
testing
lucioleKi
force-pushed
the
isabell/erts/processes_iterator
branch
2 times, most recently
from
56cdff4 to
0da4f15
Compare
lucioleKi
force-pushed
the
isabell/erts/processes_iterator
branch
from
0da4f15 to
ee5776b
Compare
lucioleKi
changed the title
processes_first/0 and processes_next/1processes_iterator/0 and processes_next/1
lucioleKi
force-pushed
the
isabell/erts/processes_iterator
branch
from
ee5776b to
6bec169
Compare
This PR adds 2 BIFs to the `erlang` module. `processes_iterator/0` returns a process iterator that can be used to iterate through the process table. `process_next/1` takes in a process iterator and returns a 2-tuple, consisting of one process identifier and a new process iterator. If the process iterator runs out of processes in the process table, `none` will be returned. By using these 2 BIFs instead of `processes/0`, one can avoid creating a potentially huge list of the pids for all existing processes, at the cost of less consistency guarantees. Process identifiers returned from consecutive calls of `process_next/1` may not be a consistent snapshot of all elements existing in the table during any of the calls. The process identifier of a process that is alive before `processes_iterator/0` is called and continues to be alive until `processes_next/1` returns `none` is guaranteed to be part of the result returned from one of the calls to `processes_next/1`.
lucioleKi
force-pushed
the
isabell/erts/processes_iterator
branch
from
6bec169 to
69f7884
Compare
|
This is amazing! We have spotted the process listing in |
|
Yes, the processes iterator will be used by the code purger process as well as the literal area collector process in OTP 28. |
|
@rickard-green fantastic! Do you think it would be also possible to purge batches of modules in the future too? Or is it a much more complex change? Or perhaps one that would not yield benefits? |
It is a much more complex change as all parts of the VM that deals with code purging needs to be tought to handle multiple address ranges instead of just one. I'm uncertain how much work it would be, but definitely more than what is in this PR. |
|
The most problematic part as I see it is the literal area collection (which will be done for all modules with a literal area which I suspect is most of the modules). During the collection all copying of all terms in message sends needs to be aware of the literal area being collected and make copies of literals in that area instead of passing references to the literals. As it is now with only one area collected at a time, this is relatively cheap, but having a number of areas to check against might get costly. |
This PR adds 2 BIFs to the
erlangmodule.processes_iterator/0returns a process iterator that can be used to iterate through the process table.process_next/1takes in a process iterator and returns a 2-tuple, consisting of one process identifier and a new process iterator. If the process iterator runs out of processes in the process table,nonewill be returned.By using these 2 BIFs instead of
processes/0, one can avoid creating a potentially huge list of the pids for all existing processes, at the cost of less consistency guarantees. Process identifiers returned from consecutive calls ofprocess_next/1may not be a consistent snapshot of all elements existing in the table during any of the calls. The process identifier of a process that is alive beforeprocesses_iterator/0is called and continues to be alive untilprocesses_next/1returnsnoneis guaranteed to be part of the result returned from one of the calls toprocesses_next/1.